This PR implements a simple, call stack-based, garbage collection.

overview

The observation is that any operator that returns an atom that was allocated before the snapshot was taken (i.e. picking an atom out of the environment) or a simple atom. e.g. NIL or 1 effectively "launder" all computation (and allocations) that went into computing its arguments into a very small amount of data.

When this happens we can reset the Allocator to the state it was in before we invoked the operator, as long as we preserve the return value.

This requires us to pre-emptively store Allocator checkpoints just in case the operator returns a simple atom. This adds overhead and we'll have to make a judgement call on whether we think it's worth it.

The cost of recording Allocator snapshots has been mitigated by:

1. creating a new subset of the existing Checkpoint, called TransparentCheckpoint that's smaller. It uses u32 instead of usize and it does not record the "ghost" counters.
2. Only operators that are likely to return a small atom trigger this behavior. See the list in src/chia_dialect.rs in gc_candidate().

restoring the Allocator

When restoring the allocator, it's important that we preserve the same behavior as we have today, with regards to counters. The atom- and pair counters are consensus critical, since we have upper limits on them. So when we restore the allocator, we have to do it transparently, and preserve counters.

The way this is done is to increment the ghost-counters by the same amount as we are freeing. This acts as if the atoms and pairs were never freed, just like it works today.

This is one important distinction between the existing checkpoint() -> restore_checkpoint() functions and the new transparent_checkpoint() -> restore_transparent_checkpoint() functions. But note that the transparent version is a subset of the existing behavior.

benchmarking

To benchmark this I picked some of the most expensive block generators from mainnet. Expensive in the number of atoms, pairs and heap-bytes allocated, but also in execution run-time.

Extending the analyze-chain.rs tool, I picked the generators at the following heights:

running these generators before and after this change gave me the following results:

comparison

run-time

peak atom count

peak pair count

peak heap size

before (main)

after (with this change)